The Internet Protocol (IP) Multimedia Core Network Subsystem (IMS) is an IP-based network framework offered by the 3rd Generation Partner Project (3GPP), and the IMS constructs an open and flexible service environment supporting the multimedia applications and offering plentiful multimedia services for the users.
In the IMS service system, the control layer is separated from the service layer, and the control layer only offers the necessary functions such as triggering, routing and charging for the service layer, rather than the specific services, while the services are totally offered by the service layer. The service triggering and control function in the control layer is implemented by the Serving Call Session Control Function (S-CSCF), and the service layer consists of a series of Application Servers (AS) which provide the specific services. The control layer (S-CSCF) controls the service triggering according to the user's subscription data and executes services on the AS, and thereby implements functions of services.
FIG. 1 is an illustration of the service triggering process, in which the service triggering process relates to the following IMS network elements: S-CSCF 101, Home Subscriber Server (HSS) 102 and AS 103.
When S-CSCF 101 receives the user registration request message or an initial request for termination or origination from an unregistered user, it downloads the service configuration data from HSS 102 through the Cx interface, and the service configuration data comprise the service-related initial filter criteria including the information such as the service triggering point, AS identifier and the priority of each initial filter criterion.
When S-CSCF 101 receives a call-in dialog establishment request, it starts a SIP dialog, creates the service point trigger from the request message, and match with the filter criteria respectively according to the priorities of filter criteria, if the match is successful, it forwards the request message to AS 103 corresponding to the filter criteria through the IMS Service Control Interface (ISC). The AS 103 executes the service logic process and after that, it sends the request message back to S-CSCF 101 through the ISC. The S-CSCF 101 continues the subsequent service triggering process and constructs the call-out request if there are no available filter criteria and forwards the request out according to the route criteria.
In the aforementioned service triggering process, in order to make the S-CSCF module able to identify that the initial request sent back to the S-CSCF by the AS is the response to the initial request sent to the AS by the S-CSCF, and determine the corresponding original dialog, in which the original dialog identifier (ODI) is introduced, and the S-CSCF module should make sure that the value selected for the ODI is unique, so as to make it uniquely identify the original dialog corresponding to the initial request. The ODI can also be used in the standalone transaction request without establishing the SIP dialog to identify that the initial request sent back to the S-CSCF by the AS is the response to the initial request sent to the AS by the S-CSCF module.
FIG. 2 is a flow chart of matching the initial request message sent back in the service triggering process in the prior art, and it describes the process of the S-CSCF module using the ODI to match the initial request message sent back by the AS with the original SIP dialog.
S201, the S-CSCF module receives a call-in dialog establishment request;
S202, the S-CSCF module starts a SIP dialog and generates an ODI which uniquely identifies the dialog;
S203, the S-CSCF module executes the service control logic and matches the request with the initial filter criteria according to the priorities of the filter criteria. If the request matches with one initial filter criterion, it executes the service triggering process;
S204, the S-CSCF module inserts the ODI into the request and forwards the request message including the ODI to the AS;
S205, after the AS executes the service process logic, it copies the ODI into the dialog establishment request message to be sent back;
S206, the AS sends the dialog establishment request message including the ODI back to the S-CSCF module;
S207, the S-CSCF module determines that the request is the response to the dialog establishment request message sent to the AS by the S-CSCF previously according to the ODI in the request message sent back, and determines its corresponding original dialog;
S208, the S-CSCF module continues to execute the subsequent service control logic and matches the request with the subsequent filter criteria with relatively low priorities. If there are matched initial filter criteria, it re-executes the service triggering process S203, and in this process, it uses the ODI generated in S201 to identify this triggering request;
S209, if there are no suitable initial filter criteria, the S-CSCF module sends the call-out request based on the route policy.
From the above process, it can be seen that in each service triggering in one session, the S-CSCF module uses the same ODI to identify the initial request message sent to the AS, and uses this identifier to determine that the initial request message sent by the AS is the response to the initial request message sent to the AS by the S-CSCF module previously, and obtains the SIP dialog corresponding to the initial request sent back according to the corresponding relationship between the ODI and the original dialog, and executes the subsequent service triggering control following the position of the latest triggering.
The S-CSCF module needs to guarantee the uniqueness of the value of the ODI, and the ODI can be encoded in different ways, for instance, it can act as one character string of the user part, a parameter or one port number, of the S-CSCF module network identifier.
The process of the standalone transaction request message (such as Message service) is similar, and the only difference is that the standalone transaction request does not establish the SIP dialog.
FIG. 3 is a flow chart of the service triggering process when the AS sends several initial request message back in the prior art.
In the present embodiment, there are two initial filter criteria: the criterion X pointing to AS1 and Y pointing to AS2, and the priority of X is higher than that of Y. When AS1 only sends one initial request back, the service triggering process comprises the following steps:
S1, the S-CSCF module receives a call-in dialog establishment request 301, starts a SIP dialog and generates the ODI uniquely identifying this dialog;
S2, the S-CSCF module executes the service control logic, finds out that the request message matches with the initial filter criterion X, executes the service triggering process, inserts the ODI into the request message and forwards the request message 302 including the ODI to AS1;
S3, after AS1 executes the service processing logic, it copies the ODI into the dialog establishment request message to be sent back, and sends the request message 303 back to the S-CSCF module;
S4, the S-CSCF module determines that the request is the response to the request message sent by the S-CSCF module previously according to the ODI in the request message sent back 303, and determines the SIP dialog correspondingly initialized in S1, continues to execute the subsequent service control logic of the SIP dialog, and finds out that the request message matches with the initial filter criterion Y, executes the service triggering process, and inserts the ODI into the request message and forwards the request message 304 including the ODI to AS2;
S5, after AS2 executes the service process logic, it copies the ODI into the request message to be sent back and sends the request message 305 back to the S-CSCF module;
S6, the S-CSCF module determines that the request is the response to the request message sent by the S-CSCF module previously according to the ODI in the request message sent back 305, and determines the SIP dialog correspondingly initialized in S1, continues to execute the subsequent service control logic of the SIP dialog, and finds out that there is no suitable initial filter criteria, and then the S-CSCF module sends the call-out request 306 based on the route policy.
However, in the matching process, it finds out that the abovementioned method has probability of error due to incorrectly matching the initial request message with the initial request message sent back.
According to research, the reason of error is that, for an initial request message sent to the AS by the S-CSCF, there might be several initial request messages sent back by the AS, such as one number service, in which when the AS receives the dialog establishment request message, it determines to call two terminals simultaneously according to the service logic, in this case, there are two dialog establishment requests sent back to call two different terminals.
In said S3 in FIG. 3, if AS1 executes the service logic and determines to send two dialog establishment requests to be sent back 303 and 303a to the S-CSCF module, and both of these two dialog establishment requests to be sent back have the same ODI and correspond to the same dialog.
In said S4 in FIG. 3, the S-CSCF module processes the request message sent back 303 first, matches with the next initial filter criteria Y, and sends the request message 304 to AS2 after triggering the service. When processing the request message 303a, 303a should match with the initial filter criteria Y since it is the one sent back of 302, while in fact, after the S-CSCF module executes the 303 request message, it considers that the filter criteria Y has been executed, and takes the request message 303a as the one sent back of the request message 304 by mistake, and matches the service filter criteria following the filter criterion Y, and there is similar confusion when processing the request sent back 305 of 304.
According to the above analysis, in the current IMS service triggering process, there are defects in the method for matching the initial request message sent by the S-CSCF module to the AS with that sent back by the AS, and since it uses the ODI to match, when one AS has several initial request messages to be sent back with the same ODI, the S-CSCF cannot correctly match the initial request message sent back to the S-CSCF module by the AS with that sent to the AS by the S-CSCF, thus there is confusion in the service triggering and it will affect the normal use of services.